Read the announcement here

Thanks Mark. It worked for me and I've had that problem for a long time.

Hey, too cool! I'm glad you found a solution to that one.

While you're in working-on-hijack mode, is there any way we can fix the old bug where two programs get run at the same time?

Example: I have two @DC @EXEC lines in my config.ini. One of them starts Emphatic, the other starts GPSapp.

When I go to the Hijack menu and select "Emphatic", what I get, instead of just emphatic, is a flickering screen of GPSapp and Emphatic flashing back and forth as they fight to draw on the same screen. This only happens intermittently, so I don't know exactly what causes it. Any ideas?

Mmm...

With the current API, the best solution would be to have one or both of those apps "fixed", to not return control to Hijack until they have finished their respective initializations..

Within Hijack and the current API, the best I could do inside Hijack would be to insert a small delay of a second or so between ;@EXEC calls, to give time for a previous exec to complete initialization before running the next one. This will slow down the boot-up by (N -1) seconds for N apps (N==2 in your case). Probably not a biggie -- how about I parameterize it, with a ;@DELAY macro or something?

Cheers

Mmm.. oh, wait a sec -- you could do this yourself, if only the empeg image had a "sleep" command installed. But since it's missing, I suppose I'll do it inside Hijack for now.

I'm actually considering making my own "empeg" distro, based on BusyBox to add lots of new Linux commands basically "for free". But meanwhile..

-ml

Okay, here's what I've done (v353). There is now a new ;@DELAY macro (no parameters) that simply pauses execution for one second, per instance.

So if you've got two apps that are clashing, you can try this in config.ini:

;@EXEC_ONCE first_app args
;@DELAY ;; pause for one second
;@EXEC_ONCE second_app args


Any better now?

>Thanks Mark. It worked for me and I've had that problem for a long time.

Oh goodie! Thanks for trying it Laura!

(waves)

Any better now?

I'm going to give it a shot and let you know. Can't tell from my desk because without the GPS unit plugged in, I can't get it to fail reliably. Next time I'm in the car I'll mess with it and see.

Of course, now that you've described the reason it happens, I have to say that I never tried simply switching the order of the @exec items because I didn't think it would have made a difference. Now it seems that might have some bearing on this problem.

In any case, I'll leave the two items in the current order to check and see if the delay fixes the problem.

Thanks for doing this, Mark! You da man.

Any better now?

Ach, no, just got it to reproduce here at my desk after adding the ;@delay statement. Select "emphatic" from the menu, press the knob to make emphatic's menu appear, and got a brief flash of "Waiting for data from GPS receiver".

I'm going to try re-ordering the items along with the ;@delay statement and try it in the car officially tomorrow or Monday.

Seems to be behaving itself better with the order reversed plus the delay statement between them. Don't know if this was due to just the order reversal or if the delay statement was a factor.

Adding a second DELAY could be enough to "fix" it, but I suspect having GPSapp last in the sequence will have the most effect -- it has to communicate with the GPSr over a slow serial link, so it's going to be the slower one to get started up.

Cheers

Yeah, all this time I had GPSapp first, so that doesn't surprise me. Now that GPSapp is second, it seems to behave itself much better. I'll report again after I've had a chance to mess with it in the car a bunch of times.

Mark, as the ext3 code is now part of your source tree, any reason why you don't/can't build a ext3 version at the same time you build the normal version?

Would save waiting for Mike to do it, or building it myself. I would have though a simple makefile change for you would be the easiest for everyone? Support obviously still via Mike.

Disk space.

-ml

Would save waiting for Mike to do it, or building it myself.

I suppose I could setup a little script to do it automatically. Checks Mark's site occasionally for new versions and automate builds. I am not sure if enough people actually download them from me to be worth the trouble though?

-Mike

Mark and Mike,

It was just a thought. I've been using the ext3 stuff since Mike did it and its great. Would never go back to ext2.

Any reason the default build can't include ext3? Wouldn't have thought that would require more than 100k of space.

I wonder how many people do use it?

Setting up ext3 is not something that all but perhaps 10 people here might ever seriously want to do -- I haven't even bothered, and I'm a Linux kernel developer by profession!

That said, the other 2000 or so Empeg owners would probably prefer to retain the extra 150-200KB of RAM for buffering music, not for dead code they'd never use.

I believe that ALL of Hijack's current features together add less than that amount of memory overhead!

Cheers

I've been using the ext3 stuff since Mike did it and its great.

Thanks, glad to know that comes in handy for people as it took quite a bit of time to get it working in the first place.

Any reason the default build can't include ext3?

It uses extra memory and is of no use unless you install the extra utils to actually convert your filesystems to ext3. So for most hijack users it would be a waste. And of course there are mixed opinions here about if ext3 is worth the overhead for a filesystem that is usually mounted read only.

I wonder how many people do use it?

I only seem to get 5 or 10 downloads of any given version from my site. Some people of course compile their own kernel or don't download every version I post. Incidentally, I'll put up a new version from work tomorrow. I just got back from CES earlier today and I am still recovering from the time in vegas

-Mike

Incidentally, I'll put up a new version from work tomorrow

OK, an ext3 version of hj353 is up on my site if you still need it.

-Mike

Thanks Mike, will grab it in the morning.